문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 게임 기획자 (문단 편집) === 시스템 디자인 (Technical Design) === 시스템 기획자는 게임 시스템을 기획한다. 게임 시스템이란 게임을 컴퓨터에서 작동시키기고 유저에게 체험시키기 위한 전반적인 프로그램 및 UI/UX 컨셉이다. '전투 시스템'은 카메라가 돌아가는 방향, 공격하거나 방어하는 방법, 상성 등을 정한다. 퍼즐게임과 같은 일부 소수 장르를 제외하고 시스템 디자인의 수준에 따라 올릴 수 있는 콘텐츠의 질과 양이 크게 차이가 나게 된다. 전투시스템이 단순하면 연계된 스킬이나 아이템같은 콘텐츠도 단순하게 나오듯이 모든 콘텐츠의 하부에는 시스템 디자인이 반드시 필요하다. 이렇게 시스템 디자인이 중요하므로 국내/해외를 막론하고 가장 으뜸으로 꼽아주는 부분이고 실제로 총감독이나 제작자 등 관리자로 가장 많이 승진한다. 시스템 기획자들 중 일부 능력이 만렙을 달리는 사람들은 회사를 나와 스스로 모바일 회사를 차리는 경우도 많고, 심지어는 리소스를 외주로 돌리고 1~3인의 소수 팀을 꾸려 개발을 하는 사람까지 생겨나고 있다. 그래서 대개의 게임 기획자는 시스템 디자인은 기본으로 맡는다. 시스템 기획은 시스템 프로그래밍의 과정에서 좀더 복잡하고 입체적인 콘텐츠를 만들기 위해 분화된 영역이다. 즉, 프로그래머가 게임을 만들다가 생긴 영역이다. 프로그래밍 아키텍처(렌더링 모듈, 객체 프레임웍) 을 가지고 무엇을 어떻게 만들 것인지 설계하는 것이기 때문에 제대로 할려면 당연히 게임 프로그래밍을 매우 많이 해 봐야 한다. 그래서 국내 [[김택진]], [[김학규(게임 제작자)|김학규]], [[송재경]] 등 유명한 시스템 기획자들은 1세대 개발자다. 국내외 시스템 기획 노하우는 이런 1세대 개발자들의 라인을 타고 전수되고 있으므로 이런 사람들 밑에서 경력을 쌓게 된다. 그런데 국내외 1세대 개발자들은 워낙 하드코어한 야근철야 마인드로 무장하여 게임개발을 하던 사람들이므로 부하들 역시 '''365일 집에 못들어가는 게 일이 되어버리는 진짜 고된 일'''을 한다는 것. 혼자서 시스템 짜고 설정잡고 개발하는 노하우가 밤샘으로 축적되다보니 어찌보면 노하우 전수도 당연히 그리 된다는 게 업계인들의 정설이다. --좋은 건 역시 거저 얻는 게 아니다-- 특히나 구현의 이해도 때문에 프로그래머와 가까운 직군이다. 가까운 정도가 아니라 형동생 하고 서로 같이 공부해서 만드는 일도 쉽게 보이며, 그러다가 결국 '''이거 그냥 니가 스크립트 짜라''' 라던가 '''내가 코딩이 끝날때 까지 같이 밤새자'''라고 까지 하는 프로그래머가 있을 정도의 도시전설도 존재한다. 툴의 발달과 기술의 발전으로 인해 기획도 그만큼의 이해도를 지녀 프로그래머의 의존도 없이 개발하게 되면서 PC, 모바일 가릴 것 없이 빠질 수 없는 직군이 되었다.[* 특히나 메이저 엔진의 구현도는 프로그래머만큼 시스템 기획자의 툴과 스크립트 활용도에 따라 크게 갈린다.] 업계에서 제일 1순위로 환영하는 기획자 경력 직종이다. 사실 이유도 고달픈 게 '''콘텐츠 시나리오 기획자는 시스템을 만들지 못하지만, 시스템 기획자는 시스템을 구축하고 콘텐츠 시나리오도 만들 수 있으니까''' 또한 시스템 구축 상황에 따라 콘텐츠나 시나리오를 좌지우지할 수도 있다. 사실상 콘텐츠 기획은 시스템 기획의 하위 영역이라고 봐도 무방하다. 실제로 실무에서는 시스템 기획에 따라 콘텐츠 기획이 영향받는 일이 대부분이다. 하지만 국내에는 시스템 기획자가 턱없이 모자라고, 신규 기획자도 굉장히 적은 편이다. 왜냐하면 우선적으로 '''그 정도로 프로그래밍/배경/3D에 대한 지식이면 전업을 고려해봐야 되지 않나.'''라는 생각을 하게 된다. 실제로 시스템 기획자에서 다른 직종으로 전업하는 사람들도 많다고 한다. 거기에 업계인들의 증언에 따르면 정말 독한 마음 먹지 않으면 하기 힘든 직종이라고 한다. 실제로 시스템 디자인이 가능할 정도의 수준이 되면 PD급 포지션이 필요한데 게임개발업이 회사나 개인이나 양극화가 심해져 살아남은 사람들만 노하우나 경험을 쌓을수 있고, 대부분 중요한 시스템 설계는 능력을 보장받은 경력직들이 맡아버리기 때문에 제대로 시스템 기획을 해볼 수 있는 기회가 매우 적은 환경도 있다. 콘텐츠 시나리오도 야근을 안 하는 건 아니다. 하지만 이들은 정해진 일정을 위해 [[야근]]을 투자하는 데에 비해 시스템 기획자는 그런 거 없다. 밤새 뭘 어떻게 구현해야 될지 그리고 그것에 대한 [[예외 처리]]는 뭔지에 대해 공부하고 작업한다. 직종 특성상 레벨이나 시나리오 기획자들과 갈등도 많은 편이다. 설정과 연출을 잡는 콘텐츠 시나리오와 다르게 구현 스펙을 잡는 역할이라 왜 그걸 만들어야 하냐 혹은 왜 그렇게 설정했느냐 등 설정 기획쪽과 온갖 줄다리기를 벌어야 하는 직업이다. 이들은 [[프로그래머]], [[게임 원화가]], 3D모델러, 애니메이터 등과 협업하기도 한다. 시스템 기획의 특성상 레벨이나 시나리오의 전계 양상과 구현 방법 등이 달라지므로 당연히 마찰이 생길 수 뿐이 없으며 잘못되거나 낙후된 시스템 기획으로 인해 다른 파트의 야근을 초래할 수 있다. 유니티 에디터에서 쉽고 편하게 할 수 있는 일을 별도의 툴을 만들어서 처리하는 경우도 있으며 이 경우 툴 자체의 유지보수 개발소요 + 스크립터의 툴 교육과 작업숙력 + 툴자체의 성능미달과 불편함이 한대 어우러져 불필요한 인력이 발생하고 야근수요가 쓸데없이 발생하기도 한다. 시스템 기획은 초창기에 한번 설계한 이후 구현에 들어가면 변경이나 확장이 매우 힘든 영역이므로 (확장 변경시 다른 콘텐츠 시스템을 전면 수정하거나 재 작업을 해야 하는등 막대한 기회비용이 발생한다) 게임 개발에 대한 노하우를 가진 숙련자에게 맡겨야 한다. 많은 회사에서 비 숙련자나 연차가 높은 기획자 등이 시스템 기획에 대한 소양이 매우 부족한 채로 중요한 판단을 대충하는 경우가 정말 많다. [[콘텐츠 부족]]은 대부분 효율적인 시스템이 설계되지 않아 콘텐츠를 올리는데 수많은 제약과 불가능함, 생산성의 문제등으로 애초 기획한 콘텐츠를 만들지 못하거나 제대로 올리지 못 하기 때문에 발생한다. 출시 후에 몇 달간 버그만 잡다가 유저들이 전부 떨어지거나 유저들의 원하는 방향의 업데이트를 못하거나 하는 게임들이 이 부류에 속한다. 뭔가 새로운 걸 만들거나 기존 것을 변경하고 싶은데 시스템 기획이 되어있지 않은 상황에서 구현만 되어 있는 상황이나 프로그래밍 파트에서 할 수 없거나 시간이 매우 많이 걸린다고 브레이크가 걸리면 그대로 포기하거나 사소한 수치를 바꾸는 업데이트 시늉만 할 수밖에 없다.[* 이른바 데이터 패치로 주요 시스템을 개발하는 것이 아닌 아이템 추가나 캐릭터 추가, 던전 상층 추가, 스테이지 추가 등과 같이 콘텐츠 볼륨만 올리는 업데이트다.] 시스템 기획자가 목표라면 당연히 프로그래머로 출발하여 게임 개발을 배우는 것이 매우 유리하다. 게임 데이터를 다루면서 다양한 장르의 특성과 구현 아키텍처를 습득할 수 있으며 직접 구현하다보면 자연스럽게 시스템을 어떻게 활용하면 무엇을 만들 수 있을지 직관적으로 이해하게 되므로 시스템 기획의 기본적인 소양을 배우게 된다. 따라서 기획의도를 관철할 수 있는 시스템에 대한 상세한 요구사항과 구현 목표를 제시할 수 있고 개발의 주도권을 가질 수 있게 된다. 이런식의 실무 레벨에서 구체적인 기획이 제시되는 프로젝트는 매우 견고하고 안정적으로 개발이 가능하다. 문제는 국내에서는 이걸 당당하게 "기획자의 영역" 이라고 선을 긋고 기획자가 당연히 하는 것으로 가르치고 있는 경우가 많이 존재한다. 그렇다고 프로그래밍을 가르치기에는 학원의 커리큘럼 구성에 문제가 생기니까 스타크래프트 월드맵 에디터를 이용한 오목만들기... 이런 걸 가지고 시스템 기획을 가르치는 학원도 있다. 분명 시스템기획을 배우기에는 이러한 메이킹툴이 상당히 좋은 교재인 것은 확실하다. 실제로 이런 메이킹툴을 만들기 위해서는 데이터 주도적 설계를 심도깊게 이해해야 한다. 문제는 시스템 기획은 메이킹 툴을 다루는 게 아니라(스크립터의 영역) 메이킹 툴 자체를 설계하는 영역이라는 것이다. 이런 차이를 이해하지 못하고 기술적인 이해가 전혀 없는 기획자들이 시스템 기획이라는 이름으로 기술적인 판단을 내리고 그것으로 인해 수많은 시행착오를 벌려 놓으며 프로젝트를 망치는 경우가 다수 존재한다. 그래서 어느정도 개발을 해본 기획자는 시스템기획을 하기 위해 스스로 프로그래밍을 배우거나 관련 리소스를 습득하게 된다. 실제로 코딩하지는 않아도 작업 스케줄을 만들 정도로 해박한 경험이 있어야 하며 프로그래머와 함께 협업을 할려면 당연히 구현 상세에 대한 이해가 있어야 한다. 기획서만 달랑 들고 게임을 개발하는 수준은 유니티나 언리얼 엔진이 보편화된 지금 매우 시대에 뒤떨어져 있는 업무이며 구시대적 발상이다. 기획자도 게임 엔진을 다루며 프로그래머와 협업을 할 수 있어야 하며 서버에 탑재될 각종 스크립트 엔진에 대한 상세와 요구를 할 수 있어야 한다. 해외는 Technical Designer와 같이 프로그래밍을 같이 할 수 있는 게임 디자이너의 수요가 많아지고 있는 추세이다. (채용공고 사이트만 가봐도 Technical Designer나 Technical Level Designer를 구하는 공고가 많이 있다. 밸브, 유비소프트, 블리자드, 라이엇 게임즈 등) 대형 MMORPG 사에서는 크게 5가지 역할로 나눌 수 있다. 시스템 방향성 설계, 룰 디자인, 데이터 구조 설계, 밸런싱, 개발 지원이다. 시스템의 기본적인 방향성을 설정하고 시스템 구조를 설계한다 (시스템 방향성 설계). 그리고 기본 방향성을 바탕으로 게임 내 규칙을 정의한다. 이때 다른 규칙들과 위배되지 않는지 유의하여 살펴본다 (룰 디자인). 그리고 게임 내 세부 데이터 구조 설계 및 역할을 설정하고 데이터 작업 편의성과 국가별 확장성을 고려하여 설계한다 (데이터 구조 설계). 또 밸런싱을 한다(밸런싱). 그리고 프로그램팀에 요구사항을 설명하고, 완성도 향상을 위해 테스트 및 튜닝을 지원한다 (개발 지원). 이런 대형 MMORPG 사에서 시스템 기획이란 게임의 규칙과 시스템을 설계하는 직무로, 게임 내 모든 제반 사항과 플레이 기획, 게임에 필요한 연산 영역 및 데이터 구조를 구성, 제작하는 역할을 한다. 실무에서 게임 기획자가 엔진을 다루지 못하면 결국 할 건 테이블 조작이나 문서작업밖에 못 한다. 모바일 개발 일선에서 기획자의 질이 낮아지고 수요가 줄어드는 이유가 여기에 있다. 언리얼 4 엔진을 사용해보면 국내처럼 기획과 프로그래밍을 나눠서 가르치고 표준을 잡는 게 얼마나 어리석은지 알게 된다. 그리고 유니티 엔진도 자체적으로 C#을 Script라고 표현하고 있다. 즉 시스템을 기획하려면 시스템 아키텍처를 알아야 하며 이를 각각 C#과 블루프린트로 구현한 것이다. 기술적인 부분에 관심을 두지 않고 공부를 하지 않고 이해도가 없는 기획자는 페이핑만 집중하고 실무에서 배제 될 확률이 굉장히 높으며, 다른 회사 자리 찾기 어려울 정도로 기획자 경력에 생존이 어렵다. '''기획자는 게임을 기획하는 사람이지 프로그래머가 아닌데 왜 [[프로그래밍]]에 대해 (귀찮게) 알아야 하나요?'''라는 의문을 갖는 사람도 있을 것이다. 대부분 이런 질문을 하는 사람들은 기획이란 콘텐츠 기획 정도로만 생각하며 어렵고 힘든 프로그래밍을 배우기 싫어하는 사람들이다. 사실 기획과 프로그래밍은 별도로 분리된 영역이 아니다. 만약 분리가 가능하다면 개발사는 게임 기획만 전문으로 하는 회사가 있어 기획서만 팔 것이고 게임 프로그래밍만 전문으로 하는 회사가 있어 어플리케이션 구현만 전문으로 하는 회사가 있을 것이다. 당연히 현실에서 이렇게 하지 않는 이유는 기획자가 제시하는 시스템으로 프로그래머가 프로그래밍하여 실제로 구현하고 그것을 바탕으로 다양한 콘텐츠를 만들기 때문이다. 시스템을 어떻게 구성하는가가 어떤 콘텐츠를 어떻게 구현할지를 결정하게 된다. 결국 기획과 프로그래밍은 작업단위가 긴밀하게 연계되어 상호피드백을 하는 영역이다. 프로그래밍 언어와 기법, 게임 엔진 등을 빠삭하게 알아서 프로그래머 없이 게임을 만들 수 있을 정도가 되라는 말이 아니다. 만약 그렇게 할 수 있다면 당신은 기획자가 아니라 프로그래머다. Lua냐 VBA냐가 중요한 게 아니다. 하나라도 좋으니 프로그래머를 이해할 수 있을 만큼 알아야 한다는 것이다. 기획자라는 직종이 생겨난 이유는 처음부터 프로그래머의 시간 낭비를 줄인다는 취지다. 따라서 기획자는 프로그래머가 뭘 만들어야 하는지에 대해 아까운 시간을 허비하며 고민하지 않도록 알려주는 역할을 수행해야 한다. 그러므로 기획자가 프로그래밍에 등장하는 각 개념들을 이해하고 있어야 한다. 간단한 예로 적 몬스터가 유저를 쫓아오거나 공격하고 도망가는 것을 구현하고자 한다. 기획자가 게임에 사용되는 [[인공지능]][* 유한상태기계, 행동트리 등.] 기법을 이해하고 있어야 프로그래머가 기획자의 의도대로 쉽게 인공지능을 구현할 수 있다. 기획자 지망생이 프로그래밍에 대한 지식이 전혀 없는 사람이라면 프로젝트 현장에서는 큰 문제가 발생한다. 인터넷에 돌아다니는 일명 '내가 짠 게임 설정'들에 다수 등장하는 'OOO게임과 같은 식', '많이/약간', '크게/작게' 같은 두루뭉실한 표현을 써 버리면 곤란하다. 또는 구현에 쓸데없이 엄청난 노력이 들거나 실질적으로 구현이 불가능한 기획을 내놓는다면 곤란하다.[* 다만 이 경우엔 케이스 바이 케이스로, 일부 프로그래머들은 되는데도 일단 여유시간을 벌기 위해 안 된다고 던져보는 경우도 있기 때문에 일단 던져보고 대화를 통해 풀어나가는 경우도 필요하다. --이건 기획자도 그런다. 가령 1주일은 걸릴거 같은데 3일만에 해오라는 경우 철야하더라도 5일은 줘야지--] 애시당초 기획자가 다른것도 아니고 같이 일하는 프로그래머와 그래픽디자이너와 이야기해야 하는데 기초지식이 전무하고 관련 용어도 모르면 같이 배정받은 동료들이 매우 힘들어지므로 지망생이라면 어느정도 기초지식과 용어들은 알아두도록하자. 이런 분들이 회사에서 정치질을 하며 밥그릇을 챙기면 문제가 아주 심각해진다. 콘텐츠 기획만 주구장창 나오고 시스템이 없는 경우가 많으며 이런 부실한 시스템에 콘텐츠를 주먹구구로 올리게 된다. 당연히 전체적인 게임의 질이 심하게 떨어지게 된다. 기술적인 이해가 없는 상태로 시스템을 디자인 하다보니 프로그래머가 다 해줄거라고 믿는 경향이 심해지게 되고 담당 프로그래머의 역량이 낮을 경우 아무리 뭘 해도 재대로 기획의도가 반영된 된 콘텐츠가 나오지 않는다. 한국 게임의 고질적인 병폐인 콘텐츠 부족이 여기서 시작되며 개발기간은 많은데 좋은 시스템이 나오지 않는 경우가 많다. 결국 프로젝트 후반부에는 기획자는 [[QA]] 아니면 운영을 하고 실제 기획 개발은 프로그래머 위주로 굴러가게 된다. 당연히 이렇게 개발이 진행되면 서로 정치질이 시작되고 게임은 그냥 다른 게임을 적당히 배낀 게임이 나오게 된다. 근래의 기획자는 [[VBA]]로 각종 툴을 직접 만드는 등[* 툴을 만들면 당연히 작업에 들이는 시간이 줄어들고, 기획에 들일 시간이 그만큼 늘어난다. 어차피 엑셀은 출근때부터 퇴근때까지 켜놔야 하는 거니, 엑셀에서 활용할 수 있는 비베는 배워둬서 나쁠게 없다.] 콘텐츠를 생산해 내고 있다. VBA가 있으면 편하기 때문에 채용공고에서 빠지지 않는다. 이런 걸 전혀 할 줄 모르면 그냥 야근하며 노가다로 때워야 한다. 개발팀의 힘을 빌리지 않고 직접 여러가지 새로운 시도를 하고 있다. 기획자라고 PPT만 붙들고 있을 것이라 생각하면 오산이다. 직접 XML 등으로 데이터를 작성하고 퀘스트 같은 스크립트를 작성하는 테크니컬한 기획자는 많이 있다. 거기에 레벨 디자이너나 컷신 연출가 등은 전부 프로그래밍 레벨에서 연결되어 있기 때문에 적어도 프로그래밍적 사고는 필수이다. 괜히 [[게임기획전문가]] 자격시험 출제기준에 VBA 등의 스크립트를 포함하는 게 아니다! 국내 기획자는 뭐라도 붙잡고 기술적인 공부에 착수가 들어갔던 게 현실이다. 실제로 대규모 프로젝트에 PD 급이나 일 잘 한다 소리 듣는 사람들을 보면 어디 컴공 출신이나 1인 개발을 했었던 경력자들도 다수 있다. 기술적인 부분을 기획자가 제대로 알아야 되는데 지도할 인력도 교육기관도 없고 그렇다 보니 결국 1~2세대 고학력자들이나 프로그래머 출신들이 PD나 메인 기획자를 맡는 경우가 꽤나 많이 생긴다. 이는 북미나 일본 등지에서 프로그래머가 기획자가 되는 것과 비슷한 테크라고 봐도 무방하다. 해외에서는 많은 기획자(디자이너,플래너)들이 프로그래머나 아트 등 타 직군에서 능력을 인정받아 승진한 사례가 많이 존재한다. 다만 꼭 그렇지도 않은게 물론 기술적인 부분 이외에도 혹은 어떠한 게임을 만들고 설계할지를 연구하는 [[UX]] 디자이너 등등 엄청나게 세분화되어 있다. [[미야모토 시게루]]는 『[[동키콩]]』 시절에는 직접적인 프로그래밍 이외의 일은 전부 했으며(게임 설계, 도트 찍기 등) 현재도 프로그래밍에 관련 없는 직군에게도 메모리 구조 같은 걸 전부 숙지시킨 다음 현장에 투입한다고 한다. 별의 커비, 대난투 시리즈의 사쿠라이 마사히로 역시 핵심적인 프로그래밍을 제외하면 혼자서 다 만들어내다시피 했으며 신인 시절의 [[코지마 히데오]]도 '''프로그래머의 종이 될 수밖에 없는 것에 실망하였다.''' 며 [[스내처]] 개발 당시 '프로그래머에게 머리를 숙이지 않도록' IF와 SWITCH 를 기본으로 한 그림, 소리, 커맨드, 플래그, 프로그램을 혼자서 직접 관리할 수 있는 간단한 스크립트 언어를 직접 만들어 낼 정도였다.[[http://blog.livedoor.jp/amatuka_blog/archives/51646496.html|#]][[https://twitpic.com/3rxr84|#]] 이 사람들은 다 대학도 안나왔거나 프로그래밍을 전공하지 않았다. 또한 기획자가 프로그래밍'''만''' 알면 된다는 사고방식이 유독 국내에 자주 존재하는데 이 또한 잘못된 풍조다. 기획자에게 가장 중요한 건 '''코딩 레벨이나 VBA를 얼마나 잘 다루는가'''가 아니라 '''무엇을 어떻게 만들지에 대한 방법론'''을 잘 알고 프로그래머의 시간 낭비를 줄이는 일이다. 이게 부족하면 노련한 프로그래머에게 지적을 당하다가 프로젝트가 진행되면 될수록 점점 시스템에서 멀어지게 될 것이다. 현업에서 기획자의 대우와 인식이 매우 나쁘며 기획자와 프로그래머의 갈등이 심한 이유도 여기에서 나온다. 기획자는 시스템을 장악하기 위해 무리한 요구나 엉뚱한 주장, 고집을 내세우게 되며 이를 감당할 만큼 우수한 프레임워크를 구현할 수 있는 프로그래머는 매우 극소수이기 때문에 회사 내부에서 서로 입지를 강화하기 위해 온갖 정치질이 난무하게 된다. 당연히 게임의 수준은 매우 떨어지게 된다. 이런 식으로 몇 년씩 수십억을 들여 개발하던 프로젝트가 출시조차 못하고 소리소문 없이 사라지게 되었다. 일본은 신입은 무조건 해당 플렛폼(게임기)의 API로 포트폴리오를 만들라고 시키는등 기획자라도 시스템을 다룰수 있도록 훈련을 시키며(그래서 이직율이 매우 낮다. 신입을 키워서 승진시키는 문화) 미국의 경우 시스템 아키텍처에 대한 경력이 있어야 게임 디자인을 할 수 있다. 또한 개발 역사가 오래되어 기획자와 프로그래머의 간극을 줄이기 위한 개발 표준이 개발사마다 잘 발달되어 있다. 국내 개발처럼 서로 밥그릇을 챙기기 위해 프로젝트를 아작내고 서로 반목과 대립을 하지 않는다. 북미만 해도 게임 학원이 우리나라처럼 기획 / 프로그래밍으로 딱 나눈 다음 가르치지 않는다. 기획을 알려면 자연스럽게 시스템을 알아야 하므로 시스템을 가르치고 지원자에 한해서 기획 테크닉을 심화해서 가르친다. 국내는 [[UX]] 디자이너나, 일부 분업화 된 기획이 잘 이뤄지지 않아 대부분에 일을 프로그래머에게 맡겨야 되고 국내 프로그래머들 또한 비협조적인 경향은 분명히 존재하여 기획자에 개발에 도움을 주는 툴의 개발이나 개조가 잘 이뤄지지 않는 편이다. 이런 비협조적인 경향은 앞서 서술했듯이 시스템을 모르는 시스템 기획자들이 매우 많기 때문이다. 프로그래머가 클래스를 만드는데 내부 변수를 기획자가 이래라 저래라 한다면 과연 개발이 재대로 될까? 이것은 국내의 문제가 아니라 프로그래밍 업무의 특성상 발생하는 갈등이다. 또한 프로그래머 또한 만들고자 하는 게임에 대한 아무런 사전 지식이나 개념이 없는 경우도 많아서 아무리 기획에서 좋은 시스템안을 가져와도 디테일을 살리지 못하는 경우가 정말 많다. 개발툴은 기획자(스크립터)의 무기와 같은 중요한 개발 인프라인데 이것에 대한 아무런 개념도 인식도 필요도 못느끼는 프로그래머는 이런 걸 귀찮고 시간낭비이며 야근을 하게 만드는 주요 원인이라고 치부하고 꺼리게 된다. 결국 기획자는 매우 조잡한 스크립트 시스템만 가지고 디자인을 해야 하고 이는 결국 게임의 질과 양을 저하시켜 콘텐츠가 부족한데 시스템은 그냥 베끼고 특색도 없는데다가 버그가 난무하게 된다. 이른바 흔한 양산형 저급 게임이 이런 개발 환경을 가지고 있는 경우가 많다. 프로그래머도 게임의 기획적인 디테일을 충분히 알아야 하고 기획자도 프로그래머의 작업 디테일에 대해 잘 알아야 한다. 예를들어 버프시스템을 기획한다음 프로그래머와 실무 회의를 하는데 프로그래머가 RPG를 해본적이 없어서 버프가 뭔지 모르는 경우에 수많은 시행착오가 기다리고 있으며 버프시스템이 가져야 할 다양한 기능이 미비하게 구현되거나 생략되어 제대로 된 시스템이 나오지 않을 수 있다. 학원 등지에서 VBA를 필수로 배우게 하는 것은 [[레벨 디자인]]을 효율적으로 하기 위해 테이블 시뮬레이션을 하려는 것이다. 엑셀에서 각 테이블의 수치와 변수를 대입하여 계산을 수행해 보고 대미지 처리과정 등을 미리 확인해 보는 시뮬레이션이다. 이는 시뮬레이션일뿐 실제 게임 엔진에서는 이렇게 산출된 공식을 또 다시 프로그래밍 코드로 구현하여 처리하게 된다. VBA를 활용하지 못하면 임의로 게임에서 구현을 하고 일일이 로그를 통해 대미지 처리 등을 프로그래머가 일일이 확인하고 기획자에게 통보하여 수정하는등 번거롭게 된다. 때문에 이는 시스템 기획이 아니라 레벨 디자인 기법에 불과하며 전체 업무에 차지하는 비중이 높은 게 아니다. 문제는 학원에서 이걸 '시스템 기획'을 위해 가르친다고 말하기 때문에 이걸 보고 다들 시스템 기획이 이건줄 아는 사람들이 정말 많다는 것인데, VBA를 적극적으로 활용하는것은 밸런스에서 주로 활용하지 시스템 기획자는 설계한 테이블의 변환이나 엑셀 업무에 매크로 활용 정도가 대부분이다. 밸런스에서 주로 다루는 부분을 학원에서도 빠지지 않고 가르치기 때문에 신입인 경우 자신이 VBA 좀 할 줄 아는 거 보고 시스템 기획자로 지원하는 경우도 많다. 기초적인 프로그래밍 지식없이 VBA로 시뮬레이션만 돌리면 설계부터 해야 되는데 써먹지도 못하고 당연히 실무에서 사용하는 시스템 기획과는 거리가 멀다. 실무 시스템 기획은 회사가 사용할 수 있는 시스템, 즉 게임 엔진, 서버 리소스, 아트 리소스 등을 이용하여 기획 의도를 어떻게 구현할지 미리 기획하는 과정이다. 물론 그 과정에서 VBA 등이 유용하게 사용된다. 즉 개발 컨셉에 맞는 게임성을 창출하기 위해 시스템을 어떻게 활용할지 시뮬레이션 하는 것이다. 하지만 이것은 완벽하게 맹신할수 없고 시뮬레이션을 돌려봐야 게임 내 코드에서 사용하는 미묘한 차이로 오차율이 금방 생겨버리는 문제도 있다. 랜덤만 해도 라이브러리로 사용하는 랜덤함수와 VBA의 산출방식이 달라서 일일이 매크로를 수정해야 되는 경우가 부지기수이고 기초적인 시스템 기획지식 없이 VBA만 돌리면 오히려 잘못 된 시스템기획만 발생하게 된다. VBA와 더불어 아키덱처 설계를 위한 프로그래밍적 지식에 대한 과정이 있어야 구체적인 시스템 구현 목표와 레이아웃이 산출되며 세부 스케줄이 나오기 때문에 개발력을 어디에 집중하여 어디까지 만들지 구체적인 예측이 가능하다. 사실상 게임 개발력은 시스템 기획에서 나오게 되는 이유도 여기에 있다. 당연히 시스템 기획은 매우 노련하고 숙련된 경력자들이 면밀하게 해야 하는 것이며 잘못된 결정과 결함으로 인해 기술적인 문제가 누적되면 프로젝트 자체가 폐기될 수도 있다. 무슨 언어든 간에 해봤다는 게 프로그래밍 언어를 전혀 모르는 사람들보다 나쁜 건 아니다. 개발 언어에 대한 이해도가 있다는 건 인력시장이 동이나다 시피한 시스템 디자이너 시장에서는 굉장한 커리어로 작용한다. 어떤 언어든 능숙하게 쓰다 보면 대부분 개발 언어 새로 배우는 기획자들도 많고 실제로 개발 언어를 알려주는 회사나 교육기관이 전무하던 시절에 아무 언어를 배워서 자기가 터득하는 경우도 더러 많다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기